Many communication systems transfer information in streams of packets. In general, each packet contains a header and a payload. The header contains control information, such as addressing or channel information, that indicate how the packet should be handled. The payload contains the information that is being transferred. Some examples of the types of packets used in communication systems include, Asynchronous Transfer Mode (ATM) cells, Internet Protocol (IP) packets, frame relay packets, Ethernet packets, or some other packet-like information block. As used herein, the term “packet” is intended to include packet segments.
Integrated circuits termed “traffic stream processors” have been designed to apply robust functionality to high-speed packet streams. Robust functionality is critical with today's diverse but converging communication systems. Stream processors must handle multiple protocols and inter-work between streams of different protocols. Stream processors must also ensure that quality-of service constraints, priority, and bandwidth requirements are met. This functionality must be applied differently to different streams, and there may be thousands of different streams.
Co-pending applications Ser. No. 09/639,966, now U.S. Pat. No. 6,760,337, Ser. No. 09/640,231, now U.S. Pat. No. 6,804,239, and Ser. No. 09/640,258, now U.S. Pat. No. 6,754,223 the content of which is incorporated herein by reference, describe an integrated circuit for processing communication packets. As described in the above applications, the integrated circuit includes a core processor. The processor handles a series of tasks, termed “events”. These events consist of tasks such as CPU processing steps as well as the scheduling of subsequent events. These subsequently scheduled events may consist of CAM lookups, DMA data transfers, or other generic events based on conditions in the current event. All events have an associated service address, “context information” and “data”. Information about the event such as the resource that requested the event, how much data is associated with the event, and other key information from the event requestor is stored in “special state” information associated with the event. When an external resource initiates an event, the external resource supplies the core processor with a memory pointer to “context” information and it also supplies the data to be associated with the event.
The context pointer is used to fetch the context from external memory and to store this “context” information in memory located on the chip. If the required context data has already been fetched onto the chip, the hardware recognizes this fact and sets the on chip context pointer to point to this already pre-fetched context data. Only a small number of the system “contexts” are cached on the chip at any one time, and their allocation needs to managed and sometimes shared among multiple processing events. Each cached “context” has an in-use counter so that one context can be associated with multiple sets of data. The rest of the system “contexts” are stored in external memory. This context fetch mechanism and the storage of these contexts in the co-processor is described in the above referenced co-pending applications.
In the circuit described in the above references co-pending applications, data and context information for a number of events are stored in buffers in a co-processor. In order to process an event, the core processor needs the service address of the event as well as the “context” and “data” associated with the event. The service address is the starting address for the instructions used to service the event. The core processor branches to the service address in order to start servicing the event.